Skip to content

docs(store): reload merges the value #2843

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: v2
Choose a base branch
from

Conversation

Legend-Master
Copy link
Contributor

Reference: #2829

@Legend-Master Legend-Master requested a review from a team as a code owner July 12, 2025 07:45
Copy link
Contributor

github-actions bot commented Jul 12, 2025

Package Changes Through d5365e9

There are 6 changes which include barcode-scanner with minor, barcode-scanner-js with minor, window-state with minor, window-state-js with minor, fs with patch, fs-js with patch

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package current next
api-example 2.0.30 2.0.31
api-example-js 2.0.26 2.0.27
barcode-scanner 2.3.0 2.4.0
barcode-scanner-js 2.3.0 2.4.0
fs 2.4.0 2.4.1
fs-js 2.4.0 2.4.1
dialog 2.3.0 2.3.1
dialog-js 2.3.0 2.3.1
http 2.5.0 2.5.1
http-js 2.5.0 2.5.1
persisted-scope 2.3.0 2.3.1
window-state 2.3.0 2.4.0
window-state-js 2.3.0 2.4.0

Add another change file through the GitHub UI by following this link.


Read about change files or the docs at github.com/jbolda/covector

@Legend-Master
Copy link
Contributor Author

Genuine question, does anyone know why it was designed to work like that or was that a mistake?

@Legend-Master
Copy link
Contributor Author

I see, it's from #295

@FabianLars
Copy link
Member

not my proudest moment though it made sense to me at that time. i mean to some degree it still does. their requirements back then were valid imo so maybe we need 2 different functions.

@FabianLars
Copy link
Member

but most of the api sucks a bit so maybe we should rethink the plugin from the ground up in v3

@Legend-Master
Copy link
Contributor Author

Legend-Master commented Jul 18, 2025

I'm thinking the more intuitive way of how it should work, is we reset the store to defaults first and then call extend to merge the values in load

@FabianLars @lucasfernog Any thoughts? Also should we change the behavior in v2 or wait for v3 for this? Asking because if the original intension was to making load work with defaults, this change will not break that usage, and unless someone actually uses the load to merge the on-disk values, we should be good

@FabianLars
Copy link
Member

FabianLars commented Jul 18, 2025

since the pr you linked was from before v2 imo we shouldn't change the behavior now. but idk both behaviors are flawed tbh

@Legend-Master
Copy link
Contributor Author

not my proudest moment though it made sense to me at that time. i mean to some degree it still does. their requirements back then were valid imo so maybe we need 2 different functions.

Yeah, that made sense to me as well, I didn't really thought about the defaults

since the pr you linked was from before v2 imo we shouldn't change the behavior now. but idk both behaviors are flawed tbh

Same thoughts now, let's wait for v3, also making 2 functions sounds good

I'm thinking 2 potential use cases

  1. merging with default: when you add in for example a new config setting, the new setting's default will not be covered up by the old config file on user's computer
  2. on the other hand, say you have a form or something, with some pre-filled default values, and in this case you want to load the exact file on disk, the defaults don't matter here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants